\section{Introduction}
\label{sec:intro}

In this paper we consider the following general problem space: Given a 
multi-channel streaming content distributor, such as ESPN3~\cite{ESPN3:URL},
UStream~\cite{ustream:URL}, or Justin.tv~\cite{JustinTV:URL}, what distribution
system would be efficient at delivering multiple content streams while being easy to
maintain, achieve high utilization, be flexible in terms of adding new resources
to the system, and provide scaleablity per content stream? ESPN3, for example,
provides live video streams of a variety of sporting events, each with
varying levels of popularity. Football and basketball will likely have more viewers
than less popular sports like track and field or cricket. Given a cluster of
servers, what system can organize itself so multiple content
streams can use the same cluster while only using resources proportional to each
stream's viewership?

We look at the system as a group of servers that participate in multiple
multicast groups where each multicast group is for a different content stream
(\eg{} for ESPN3 each stream is a different sporting event). These multicast
groups use a mesh overlay where each server
distributes to a constant number of neighbors. A mesh provides redundancy that
reduces the impact of losses and equalizes the work each member. Once the
servers receive the content, they will push it to interested clients.

In order for servers to discover which multicast groups exist in the system and
potentially join those groups, we have an ``organization'' multicast mesh that
all servers are a part of. This mesh lets servers locate groups in the system
that its clients are interested in and, if necessary, join those groups. It also
lets new servers join the system easily for scalability and maintainability; all
network configuration is done in a distributed manner, meaning there is no
single point-of-failure for the entire service.

The rest of the paper is divided as follows. Section ~\ref{sec:design} discusses
the design of \sysname{}. Section ~\ref{sec:eval}, evaluates a
prototype of our system as well as model to simulate larger clusters. Section
~\ref{sec:related} looks at related work for multicast overlays. Section
~\ref{sec:futurework} looks at future work and section
~\ref{sec:conclusion} contains our conclusions.
